Field of the Invention
Example embodiments relate generally to a system and method for cooperative application control using Long-Term Evolution (LTE) Radio Access Network (RAN) metrics.
Related Art
FIG. 1 illustrates a conventional network 10 with mobile User Equipment (UE) 110 connected to the Internet Protocol (IP) Packet Data Network (IP-PDN) 1001 (also referred to as internet) wirelessly via 3rd Generation Partnership Project Long-Term Evolution (3GPP LTE) IP Connectivity Network (IP-CAN) 100 (also referred to as a wireless network). The IP-CAN 100 generally includes: a serving gateway (SGW) 101; a packet data network (PDN) gateway (PGW) 103; a policy and charging rules function (PCRF) 106; a mobility management entity (MME) 108, and an Evolved Node B (eNB) 105 (also referred to as cell). The IP-PDN 1001 includes Application Function (AF) 109 which may include application or proxy servers, media servers, email servers, other connected UEs, etc.
Within the IP-CAN 100, the eNB 105 is part of what is referred to as an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (EUTRAN), and the portion of the IP-CAN 100 including the SGW 101, the PGW 103, and the MME 108 is referred to as an Evolved Packet Core (EPC). Although only a single eNB 105 is shown in FIG. 1, it should be understood that the EUTRAN may include any number of eNBs. Similarly, although only a single SGW, PGW and MME are shown in FIG. 1, it should be understood that the EPC may include any number of these core network elements.
The eNB 105 provides wireless resources and radio coverage for UEs including UE 110. For the purpose of clarity, only one UE is illustrated in FIG. 1. However, any number of UEs may be connected (or attached) to the eNB 105. The eNB 105 is operatively coupled to the SGW 101 and the MME 108. The UE 110 may also include an application function 115 that may run applications on the UE 110, where the applications may be sourced from an application or proxy servers, media servers, email servers, other connected UEs, etc.
The SGW 101 routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers of UEs. The SGW 101 also acts as the anchor for mobility between 3rd Generation Partnership Project Long-Term Evolution (3GPP LTE) and other 3GPP technologies. For idle UEs, the SGW 101 terminates the downlink data path and triggers paging when downlink data arrives for UEs.
The PGW 103 provides connectivity between the UE 110 and the external packet data networks (e.g., the IP-PDN) by being the point of entry/exit of traffic for the UE 110. As is known, a given UE may have simultaneous connectivity with more than one PGW for accessing multiple PDNs.
The PGW 103 also performs policy enforcement, packet filtering for UEs, charging support, lawful interception and packet screening, each of which are well-known functions. The PGW 103 also acts as the anchor for mobility between 3GPP and non-3GPP technologies, such as Worldwide Interoperability for Microwave Access (WiMAX) and 3rd Generation Partnership Project 2 (3GPP2 (code division multiple access (CDMA) 1× and Enhanced Voice Data Optimized (EvDO)).
Still referring to FIG. 1, the eNB 105 is also operatively coupled to the MME 108. The MME 108 is the control-node for the EUTRAN, and is responsible for idle mode UE paging and tagging procedures including retransmissions. The MME 108 is also responsible for choosing a particular SGW for a UE during initial attachment of the UE to the network, and during intra-LTE handover involving Core Network (CN) node relocation. The MME 108 authenticates UEs by interacting with a Home Subscriber Server (HSS), which is not shown in FIG. 1.
Non Access Stratum (NAS) signaling terminates at the MME 108, and is responsible for generation and allocation of temporary identities for UEs. The MME 108 also checks the authorization of a UE to camp on a service provider's Public Land Mobile Network (PLMN), and enforces UE roaming restrictions. The MME 108 is the termination point in the network for ciphering/integrity protection for NAS signaling, and handles security key management.
The MME 108 also provides control plane functionality for mobility between LTE and 2G/3G access networks with the S3 interface from the SGSN (not shown) terminating at the MME 108.
The Policy and Charging Rules Function (PCRF) 106 is the entity that makes policy decisions and sets charging rules. It has access to subscriber databases and plays a role in the 3GPP architecture as specified in 3GPP TS 23.303 “Policy and Charging Control Architecture”. In particular PCRF via PGW may configure wireless bearers, and PCRF also may configure policies on PGW and SGW related to flow control of the packets that belong to a particular bearer. A “bearer” may be understood to be a virtual link, channel, or data flow used to exchange information for one or more applications on the UE 110.
The Application Function (AF) 115 in the UE 110 communicates with the Application Function (AF) 109 via IP-CAN 100 to establish application session, receive and send application content and other application specific information. AF 109 may be a server in IP-PDN, or a peer end user device or a combination of these. AF 109 may register with PCRF 106 to receive application level policy that may enable adapting application behavior to help improve end user quality of experience.
FIG. 2 is a diagram of a conventional E-UTRAN Node B (eNB) 105. The eNB 105 includes: a memory 240; a processor 220; a scheduler 210; and communication interfaces 260. The processor 220 may also be referred to as a core network entity processing circuit, an EPC entity processing circuit, etc. The processor 220 controls the function of eNB 105 (as described herein), and is operatively coupled to the memory 240 and the communication interfaces 260.
The eNB may include one or more cells or sectors with a shared wireless resource pool serving UEs within individual geometric coverage sector areas. Each cell individually may contain elements depicted in FIG. 2. Throughout this document the terms eNB, cell or sector shall be used interchangeably.
Still referring to FIG. 2, the communication interfaces 260 include various interfaces including one or more transmitters/receivers connected to one or more antennas to transmit/receive (wireline and/or wirelessly) control and data signals to/from UEs or via a control plane or interface to other EPC network elements and/or RAN elements. The scheduler 210 schedules control and data communications that are to be transmitted and received by the eNB 105 to and from UEs 110. The scheduler 210 may include a dedicated processor for performing these scheduling functions, or the scheduler 210 may reside in processor 220 (as shown in FIG. 2). The memory 240 may buffer and store data that is being transmitted and received to and from eNB 105.
Every Transmission Time Interval (TTI), typically equal to 1 millisecond, the scheduler may allocate a certain number of Physical Resource Blocks (PRBs) to different bearers carrying data over the wireless link in the Downlink (from eNB 105 to UE 110) and Uplink (from UE 110 to eNB 105) directions. The scheduler may also determine Modulation and Coding Schema (MCS) that may define how many bits of information may be packed into the allocated number of PRBs. The latter is defined by the 3GPP TS36.213 tables 7.1.7.1-1 and 7.1.7.2.1-1, which presents a lookup table for a number of bits of data that may be included in PRBs sent per TTI for a given allocated number of PRBs and a MCS value. MCS is computed by the scheduler using Channel Quality Indicator (CQI) values reported by the UE 110 that in turn may be derived from measured by the UE 110 wireless channel conditions in the form of Signal to Interference and Noise Ratio (SINR).
Scheduler 210 may make PRB allocation decisions within the shared wireless resource pool based upon a Quality of Service (QoS) Class Identifier (QCI), which represents traffic priority hierarchy. There are nine QCI classes currently defined in LTE, with 1 representing highest priority and 9 representing the lowest priority. QCIs 1 to 4 are reserved for Guaranteed Bitrate (GBR) classes for which the scheduler maintains certain specific data flow QoS characteristics. QCIs 5 to 9 are reserved for various categories of Best Effort traffic.
While the scheduler operations are not standardized, there are certain generic types of schedulers that are generally accepted. Examples include strict priority scheduler (SPS) and proportional weighted fair share scheduler (PWFSS). Both types try to honor GBR needs first by allocating dedicated resources to meet whenever possible the GBR bearer throughput constraints while leaving enough resources to maintain certain minimal data traffic for non-GBR classes. The SPS allocates higher priority classes with all the resources that may be needed (except for a certain minimal amount of resources to avoid starving lower priority classes), and lower priority classes generally receive the remaining resources. The PWFSS gives each non-GBR QCI class certain weighted share of resources that may not be exceeded unless unutilized resources are available.
It should be understood that with a Virtual Radio Access Network (VRAN) architecture, various eNB functions and components may be distributed across multiple processing circuits and multiple physical nodes within a VRAN cloud. Likewise, with a virtualized wireless core network architecture, various functions and components of MME 108, P-GW 103, S-GW 101, PCRF 106 may be distributed across multiple processing circuits and multiple physical nodes within a Virtualized Wireless Core cloud.
Hypertext Transfer Protocol (HTTP) Adaptive Streaming (HAS) is a widely adopted technique to deliver Video on Demand (VoD) services. Video is segmented into short segments (typically 2 to 10 seconds in duration), where each segment is encoded at multiple video formats/resolutions and rates. A HAS client maintains a cache buffer for video data received at the HAS client in order to smooth out any variability of network conditions. The HAS client runs a Rate Determination Algorithm (RDA) to select a video rate for the next video data segment (located in a Content Cache of pre-encoded video segments) based on the HAS client's estimates of network throughput (which the HAS client may obtain by dividing a video segment size by the time elapsed between sending request for the video segment and completing the video segment download), the HAS client's cache buffer fullness and various heuristics. A higher video rate for a segment yields sharper picture quality and better end user quality of experience (QoE) at the expense of larger video segment sizes and more bandwidth required to deliver such segments. On the other hand, a lower video rate requires less bandwidth resources to deliver the video segment, but may be associated with more blurry or sometimes blocky picture quality. The use of various heuristics may ensure a certain level of stability in rate selection for different video segments, as frequent variations in the rate selection from one video segment to another may contribute to a low user QoE.
Different variations of HAS have conventionally been implemented by application vendors. 3GPP and International Telecommunication Union (ITU) came up with the Dynamic Adaptive Streaming over HTTP (DASH) standard to standardize the format in which HAS application clients receive information about available video segment formats and locations of the segments, which are described in the DASH Media Protocol Descriptor (MPD) file (also called a manifest file).
Conventionally, under severe wireless network congestion conditions, a number of UE's able to watch mobile adaptive streaming video over a Best Effort wireless link is often times significantly less than it could be, based upon available wireless link capacity under the congestion conditions. One reason for this is mobile hypertext transfer protocol (HTTP) Adaptive Streaming (HAS) applications are greedy and non-cooperative. Under congestion conditions, HAS applications (which currently predominantly use a Best Effort LTE service class for most networks) suffer from lack of awareness about available RAN resources. Therefore, the UE's, and the HAS applications being run on the UE's, are unable to maximize the available RAN resources in a cooperative fashion. In particular, each HAS application individually tries to maximize its share of RAN resources within the limits determined by an individual video segment rate determination algorithm (RDA). As such, each mobile HAS application selects a highest video play rate allowed by the RDA estimated network throughput. If the play-ahead buffer is not full (i.e., adaptive streaming application is in a “hungry state”), HAS application tries to obtain video segments as quickly as possible, resulting in RAN resource consumption significantly higher than a selected video rate. As a result of such individually greedy behavior, under RAN congestion conditions a number of UEs that actually receive HAS video may be significantly less than it may be with the cooperative utilization of the available RAN resources.
FIG. 3 graphically depicts simulation results for a conventional wireless network with 18 Best Effort HAS clients served by a same 10 Mhz cell (where other network traffic may also be present, but is not shown). An original 6 HAS clients 400 are later joined by 12 more HAS clients 402, thus creating a congestion condition. All HAS clients in this simulation are watching videos encoded at multiple video rates with the lowest available video rate being about 500 Kbit/sec. After the congestion starts, only 2 clients 400a (out of 18 total clients) that have the best channel conditions have video (non-empty play-ahead buffers). The remaining 16 clients have worse channel conditions, so the fair share of physical resource blocks (PRBs) that the scheduler allocates to them is not sufficient to sustain even the lowest available video rate. Therefore, only 2 clients out of a total of 18 clients may be served while running HAS applications in a conventional network.
Conventionally, a solution exists for optimizing UE's running HAS applications that is associated with enforcing throughput limits at the eNB for each individual HAS client, by assigning each HAS client a Guaranteed Bit Rate (GBR) service class, instead of Best Effort (for instance). However, this solution is not feasible, for at least two reasons. First, such a solution would be expensive to implement. In particular, some network operators consider GBR economically impractical, especially in an environment catering to flat rate data plans. Second, UEs in worse channel conditions may consume significantly more resources (PRBs) to maintain a guaranteed rate, which may further exacerbate the problems associated with congestion conditions. For example, FIG. 4 graphically depicts that out of the 18 UEs shown in FIG. 3, only two UEs 400a are experiencing a ‘best channel condition’ state, whereas the remaining 16 UEs are in worse channel conditions. The graphical representation of FIGS. 3 and 4 may be considered typical channel conditions for purposes of HAS applications. While the issues related to UEs in worse channel conditions may be alleviated by using an Adaptive GBR (AGBR) service class technique where the amount of resources allocated to a UE is also limited by the channel conditions, the telecommunication industry is conventionally only studying the feasibility of adopting an AGBR approach, as the majority of HAS traffic utilizes a Best Effort approach.
Conventionally, there is no mechanism for application level admission control and resource distribution policies that would be capable of enforcing HAS clients to use Best Effort wireless resources in a cooperative fashion, while maximizing the number of UEs able to play video under congestion conditions. Likewise, conventionally there are no admission control and resource distribution policies to prevent UEs in poor channel conditions (below the lowest required video rate) from usurping network resources while attempting to play HAS video, nor are there any conventional mechanisms for distributing available RAN resources properly among “admitted” UEs to ensure that all admitted UEs successfully play video while also maximizing the number of admitted UEs.